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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 

The present document defines the TISPAN NGN Release 2 IPTV architecture: Dedicated subsystem for IPTV functions 
in NGN. 



Introduction 



The present document provides an architectural framework for the end-to-end Internet Protocol Television (IPTV) 
subsystem within the Next Generation Networks architecture. The IPTV framework is designed for interoperability with 
other NGN service subsystems and components. 

The present document identifies functional entities and reference point, which needs to be exposed from IPTV 
subsystem. 
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Scope 



The present document describes the IPTV functional architecture and functions of an IPTV system by and incorporating 
integration of IPTV functions subsystem within into the NGN architecture. For example, interactions and information 
flows between the IPTV system functional entities with and other functional entities will be specified. The specification 
starts from outlining high-level IPTV functional architecture, functional groups and is further developed into the more 
detailed functional architecture, reference points and operational modes. 

The architecture is intended to support requirements defined by the respective ETSI TISPAN requirement 

definitions [1] and allow integration new or existing IPTV solutions (such as those defined by DVB, ATIS IIF, ITU etc) 

within the NGN architecture. 

The resulting architecture should, should rely as much as possible on common components and integrates, coexist with 
other TISPAN NGN services. 

The following areas are covered: 

• Authentication and authorization. 

• Content Protection (including DRM). 

• Capability exchange. 

• Resource Management. 

• Policy Management. 

• Charging. 

• User Profiles. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were vaUd at the time of publication ETSI cannot guarantee 
their long term validity. 
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2.1 Normative references 



The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[I] ETSI TS 181 016: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN services and 
IPTV". 

[2] ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[3] ETSI TS 122 240: "Universal Mobile Telecommunications System (UMTS); Service requirements 

for 3GPP Generic User Profile (GUP); Stage 1 (3GPP TS 22.240". 

[4] ETSI TS 123 240: "Universal Mobile Telecommunications System (UMTS); 3GPP Generic User 

Profile (GUP) requirements; Architecture (Stage 2) (3GPP TS 23.240)". 

[5] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture Release 1". 

[6] ETSI TS 182 027: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS 

subsystem". 

[7] ETSI ES 282 019: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Functional Architecture; Resource and Admission Control 
Subsystem (RACS)". 

[8] IETF RFC 2782: "A DNS RR for specifying the location of services (DNS SRV)". 

[9] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[10] ETSI ES 282 004: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment 

Sub-System (NASS)". 

[I I] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); Resource and Admission Control Sub-system (RACS); 
Functional Architecture". 

[12] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Security; Security Architecture". 

[13] ETSI ES 282 010: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Charging [Endorsement of 3GPP TS 32.240 v6.3.0, 
3GPP TS 32.260 v6.3.0, 3GPP TS 32.297 v6.1.0, 3GPP TS 32.298 v6.1.0 and 3GPP TS 32.299 
V6.4.0 modified]". 

[14] ETSI TS 132 240: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Charging management; 
Charging architecture and principles (3GPP TS 32.240)". 

2.2 Informative references 

[15] ETSI TR 187 008: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NAT traversal feasibility study report". 
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Abbreviations 



For the purposes of the present document, the following terms and abbreviations apply: 

BC Broadcast 

BTV Broadcast TV 

CA Conditional Access 

CF Customer Facing 

CoD Content On Demand 

DNG Delivery Network Gateway 

DRM Digital Rights Management 

FE Functional Entity 

GUP Generic User Profile 

IMS IP Multimedia Subsystem 

IPTV IP Television 

lUDF IP User Data Function 

MCF Media Control Function 

MDF Media Delivery Function 

NASS Network Attachment Subsystem 

RACS Resource and Admission Control Subsystem 

SD&S Service Discovery & Selection 

UDAF User Data Access Function 

UDF User Data Function 

UE User Equipment 

UPSF User Profile Server Function 



NGN IPTV subsystem 



This clause outlines architectural approach adopted in the present document. The approach is then applied to introduce 
high level IPTV architecture and functional groups in NGN architecture. 

4.1 Concept and Architectural Approach 

The document focuses on defining flexible functional architecture, which can: 

• allow development of new IPTV subsystem in NGN; 

• integrate existing IPTV subsystem in NGN; 

• extend both to support other NGN services; 

as defined in the service level requirements [ 1 ] . 

The support for other NGN services has a wide meaning, e.g. the functional architecture would allow coupling 
functionality of IPTV subsystem with functionality of PES or IMS subsystem, which in-turn may support some IPTV 
features as defined in [6]. 

In order to achieve high level of flexibility, the work is focused on identifying and standardizing functional entities and 
reference points, which needs to be exposed from IPTV subsystem to the rest of NGN. Internal IPTV functional entities 
and reference points are identified and described for the completeness of the end to end architecture without intend to 
standardize them. 

The architectural approach considers IPTV subsystem as a functional area, which is integrated into NGN via 
standardized reference points and delivers service level requirements, while allowing internal flexibility and extensions 
for new service types. 

The IPTV dedicated subsystem is based upon IPTV domains defined in TS 181 016 [1], clause 4.1 IPTV Roles. 
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4.2 High Level Architecture Overview 

Figure 1 presents high-level NGN IPTV functional overview and location of IPTV capabilities in the TISPAN NGN. 
The high level overview illustrates principal functional groups for NGN IPTV services. The functional groups map to 
IPTV roles as defined in clause 4.3. 

The functional groups are used to derive more detailed functional architecture, however, allocation of functions across 
operational and organizational boundaries will vary between implementations. 



End-User 
Functions 



Application Functions 



IPTV Service Control 

And Media Delivery 

Functions 



Transport Functions 



Manage- 
ment 
Functions 



Content 
Provider 
Functions 



Figure 1 : High-level NGN IPTV functional architecture 



4.3 Functional groups 



In the context of the present document functional groups are used to describe several functional entities grouped 
together according to some condition, e.g. location in the certain functional layer. 

4.3.1 Application Functions 

Within the present document, the term "Application Functions" includes IPTV and NGN Application Functions. 

NGN Applications: provides the user with rich multimedia applications distributed across multiple NGN subsystems. 
For example, session follow up or messaging exchange between fixed and mobile terminals, presentation of incoming 
calls and phone list management on TV, IPTV or gaming applications based on user presence. NGN applications also 
provide operators with centralized NGN management interface to multiple subsystems for content management, 
charging, interactions with IMS services, others. NGN applications may include application functions used across 
multiple service domains for applications interactions, e.g. IMS and IPTV interactions. NGN applications may include 
service mediation and coordination functionality. 

IPTV Applications: customer facing and operator facing. 

Customer facing IPTV applications provides the server side functions to enable customer facing IPTV applications, 
expose IPTV services to other NGN application and manage IPTV subsystem. Customer facing IPTV applications 
provide service provisioning, selection and authorization of IPTV services. 

Operator facing IPTV applications provide operator control over IPTV subsystem in NGN, content preparation and 
media management, content licensing, subscriber management, offer creation, user profiles. 

Server side IPTV applications expose IPTV services to NGN. 
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4.3.2 IPTV Service Control and Media Delivery Functions 

Enables operation of IPTV services in NGN. The key functionality of this layer is to provide, but not limited to, media 
distribution, selection and allocation of media delivery units, IPTV session control and management, interactions with 
other NGN components for admission control and resource allocation, as well as collecting charging and QoS 
information. 

4.3.3 Transport Functions 

Transport Control Functions: contains common NGN components RACS and NASS, provides policy control, 
resource reservation and admission control as well as IP address provisioning, network level user authentication and 
access network configuration as defined in TISPAN. Transport layer definition includes definition from [5]. 

Transport Processing Functions: the Transport Process Functions represents network access links and IP core. The IP 
core is in charge of data transmission with quality of service support. 

4.3.4 End User Functions 

Customer transport: provides connection to one or multiple access networks and one or multiple home network 

segments. 

UE: provides user interactions and control over delivery of IPTV and other NGN services. IPTV terminal processes 
serviced multimedia and presents it in user acceptable format. User interactions may include service discovery, 
selection and authorization. Multimedia processing may include requesting multimedia asset in supported encoded 
format, decoding and presenting it to the user in acceptable format, trick mode operators, channel change. 

4.3.5 Management Functions 

The IPTV Management Functions include: 

Service Fulfilment: the functions required to fulfil the IPTV service to the End-User. 

Service Assurance: the functions required to assure the IPTV service provided to the End-User. 

Service Billing: the functions required to ensure proper billing to the end user of delivered IPTV services. 

4.3.6 Content Provider Functions 

The functions provided by the entity that owns or is licensed to sell content or content assets. These are normally the 
sourcing of content, metadata and usage rights. 



5 NGN dedicated IPTV subsystem functional 

architecture 

The context of the IPTV architecture is represented "end to end" for completeness, starting from the UE on the left to 
the management functions and content providers functions on the right. However, the functions on the right 
(e.g. management and content provider) are outside this release of the specification. 

Dedicated NGN IPTV functional architecture is presented in figure 2. 
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Figure 2: NGN IPTV functional architecture 

The figure also includes reference points using dotted lines, which are shown for completeness and outside the present 
document: examples are provided in informative annex showing how such reference points can be used. The two 
reference point outside the scope of the present document shown for completeness are NGN & Customer facing IPTV 
application interactions and Configuration and Authentication. 

The focus of the current specification in on the functions in the middle, namely IPTV functions in the service layer and 
in the transport layer for integration into NGN. 

The functions performed by the service layer are grouped into two levels: 

• the application functions for provisioning an IPTV service consumption by a given user (e.g. service 
selection, where 'selection' is used in a wide sense, e.g. including the parental control rules, others); 

• the IPTV service control and delivery functions for the execution of a given instance of an IPTV service 
during service consumption (e.g. the user can experience and control the delivery of a given media content) 
and for the selection of Media Control Function and media delivery during the IPTV service establishment. 

The functions performed in the transport layer apply the principles of TISPAN NGN networks transport layer (see 
definition in [5]) to enable policy control, resource reservation, admission control, IP address provisioning, network 
level user authentication. The relationship between media management, media distribution and media preparation 
functions are presented for the completeness. However, interface definitions are outside the scope of the current release, 
which is represented by the dotted lines. 
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5.1 Functional entities 

The functional groups presented on figure 1 contain the following functional entities used to deliver NGN IPTV 

services. 

NGN Application FE: application providing functionality across single or multiple subsystem, e.g. messaging 
exchange between fixed and mobile terminals, presentation of incoming calls and phone list management on TV, IPTV 
gaming applications based on user presence, NGN applications may include service mediation and coordination 
capabilities. 

NGN User Data Access FE (NGN UDAF): The NGN UDAF knows the location and gives access to user data. An 
instance of it can be either GUP server if data federalization approach is selected, known NGN application, or other 
legacy solutions. 

User Profile Server FE (UPSF): The user profile server function (UPSF), as defined in ES 282 001 [5], is responsible 
for hosting a set of user related information, amongst service-level user identification, numbering and addressing 
information., service-level user security information: access control information for authentication and authorization, 
service-level user location information at inter-system level, service-level user profile information. 

NGN Application User Data FE (NGN App UDF): NGN App user data function is responsible for handling NGN 
application and user data. NGN App UDF allows integration of application data across NGN applications either using 
3GPP data federalization ([3] and [4]), known NGN application, e.g. UPSF, or other legacy solution. 

IPTV User Data FE (lUDF): IPTV user data function. IPTV user data function is responsible for handling dedicated 
IPTV user data. lUDF allows integration of user data from IPTV subsystem into NGN either using 3GPP data 
federalization ([3] and [4]), known NGN application, e.g. UPSF, or other legacy solution. 

Customer Facing IPTV Application FE: provides IPTV service provisioning, selection and authorization: 

Provide IPTV services offer. 

Enable navigation and selection. 

Verify access right according to the IPTV user profile, e.g. stored in the UPSF. 

Provides authentication and authorization to validate the user's right based on the user profile. 

Authorizes the UE to access the IPTV Service Control and Delivery Functions. 

Provides to the UE initial entry point to the selected service. 

May provide to the UE information on selected IPTV service (e.g. duration, range, etc.). 

May access to the NASS in order to request the geographical user localization. For example, to deliver SD&S 
metadata according to the localization of the user, support user nomadism. 

May provide application usage control like COD credit, COD already purchase with last play range. 

SD&S: provides description information for discovery of the service list for Live TV and selection of these services or 
on-demand IPTV services. Particular implementation is outside the scope of the present document, e.g. defined in [2] 
can be used. 

IPTV Subscriber Management FE: manages IPTV subscriber database. 

IPTV Control FE: 

• Checks if UE has been authorized by the Customer Facing IPTV Application to use IPTV Service Control and 
Delivery Functions. 

• Provides selection of the Media Control Function during the IPTV service selection ( optional in case of one to 
one relationship between IPTV Control entity and Media Control Function entity): 

Based on location of the Media Control Function (MCF) entity. 

Based on load of the Media Control Function (MCF) entity. 
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Based on distribution of contents among media delivery entity. 

Optionally based on resource admission control between UE and media delivery entity. 

• May retrieve in NASS the geographical user localization, to select the Media Control Function entity. 

Media Preparation FE: a group of functions for manipulating, 'preparing', content to enable content delivery to the 
UE. Examples of content preparation are encryption, encoding, keys and access rights generation. Such processes may 
be executed off-line, being considered as belonging to media content management, or on-line, in real-time, then being 
part of the IPTV applications or service delivery and control, e.g. DRM processing may be delegated. 

Digital Rights Management (DRM) Function: Conditional Access (CA), implements encryption and conditional 
access for instances of multimedia service delivery. 

Media Acquisition Function: belongs to the media preparation functions. Implements media acquisition functionality 
acquiring the media content from the content providers, may acquire license rights from the content providers to enable 
media distribution to delivery functions. Media acquisition function can be co-located with media delivery function, e.g. 
for acquisition of live media streams. 

Media Distribution FE: implements media distribution functionality, e.g. physical distribution of multimedia assets 
from centralized location to distributed delivery grid via protocols or life access to broadcast channels. 

NOTE: There are relationships and interfaces between Media preparation FE, Media distribution FE, MCF/MDF 
functional elements and content management may be used to purpose manage content ingest as described 
in management clause 8. 

Media Control Function (MCF): 

• Handling media flow control of MDF (not applicable for multicast e.g. Linear TV). 

• Monitoring the status of MDF. 

• Managing interaction with the UE (e.g. trick mode commands). 

• Handling interaction with the IPTV control function. 

• Keeping an accurate view on status and content distribution related to the different MDFs that it controls. 

• Selecting an MDF, in the case an MCF controls multiple MDFs different criteria, may be applicable as for 
example as follows: 

Load balancing of media delivery entities (MDF). 

Based on distribution of contents among media delivery entities. 

Optionally location of the UE (may need to access NASS in order to request the geographical user 
localization, e.g. to select the Media Delivery entity according to the localization of the user and to select 
nearest MDF). 

Optionally based on resource admission control between UE and media delivery entity or availability of 
content/resources in MDF itself. 

• May check user authorization to use requested IPTV service. 

• May generate charging information, e.g. for end-user charging based on the viewed content. 

• May manage the media processing of MDF. 

In IPTV dedicated subsystem MCF acts as UE point of contact for requested delivery of the selected IPTV service. 
Media Delivery Function (MDF): 

• Handling media flow delivery (delivering multimedia services to the user). 

• Status reporting to MCF (e.g. reporting on established IPTV media session). 
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• Storing of media (e.g. CoD assets), may store some service information with media for IPTV services. 

• In particular, may be used for storing the most frequently accessed content or user specific content 

(e.g. recording PVR, Time Shifted TV, Pause TV, user generated content) if the same tasks are not performed 
byUE. 

• May additionally process, encode or transcode (if required) media to different required media formats (e.g. TV 
resolution depending on terminals capabilities or user preferences). 

• May perform content protection functionalities (e.g. content encryption). 

• May support content ingestion of IPTV media. 

For BC services MDF may act as source for multicast streams of BC media streams. 

RACS: TISPAN resource admission and control subsystem. 

NASS: TISPAN network attachment subsystem. 

Charging and Accounting Functions: manage customer charging and service subscriptions. 

Transport Processing Functions: as defined in clause 4.3. 

Customer Transport Functions: 

• Delivery Network Gateway (DNG): device that is connected to one or multiple access networks and one or 
multiple home network segments. 

• User equipment function: provides user interactions and control over delivery of IPTV and other NGN 
services. May include the following elementary functions: 

Broadcast-Client Function. 

On-Demand Client Function - provide interfaces with on demand headend components and enable end 
user application. 

Audio/Video Decoder Function. 

Audio/Video Decryption Function. 

Optional support for sub-title function. 



5.2 Reference points 



5.2.1 Tr - IPTV transactional 

Reference point between UE and Application Functions: 

• Used for UE Authentication and Authorization during initialization. 
NOTE 1 : UE authentication may also be done directly via e2 reference point. 

• Used for user Authentication and Authorization for IPTV service during initialization. 

• Used to provide UE with one or more service offers. 

• Used to enable navigation and service selection. 

• May instantiate IPTV/converged service offers. 

NOTE 2: The relation to converged service needs further clarification and this is not an «IPTV topic». 

• Can give access to personalized offers from multiple service domains based upon user profile. 

• Provides to the UE an initial entry point into the IPTV service level subsystem. 
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• Provides to the UE information on selected IPTV service. 

5.2.2 Ct2 - UE facing IPTV control 

Optional reference point between UE and IPTV Control: 

• Acts as initial UE point of contact to request delivery of the selected IPTV service. 

• Returns nominated service (media) delivery control function. 

• Provides enough information for IPTV Control to check that UE has been authorized (by the Customer Facing 
IPTV Application) to access the requested resources. 

NOTE: "Optional reference point" refers to a reference point only required in some of the operational modes: 
proxy, redirect, coupled or decoupled as defined in clause 6. 

5.2.3 Sa - IPTV control and Media Control Function 

Reference point between IPTV control and Media Control Function: 

• Used to interact with the Media Control Function (MCF) entity of the IPTV service selected by a user 
(e.g. provides information to the MCF that the user is authorized to access the selected IPTV service). 

• Used to notify the IPTV control with information related to the service selected (e.g. the IPTV service cannot 
deliver the service because of network reasons such as insufficient bandwidth or no media delivery available). 

NOTE: This interface is not used to make the media delivery (MDF) selection; this is the role of the MCF. 

5.2.4 Ss - Service selection 

Optional Ss - Service selection reference point between Customer facing IPTV applications and IPTV control: 

• Used to notify the IPTV control entity of the IPTV service selected by the user. 

• Used to notify the Customer Facing IPTV Application the UE initial entry point to the selected service (Media 
Control Function). 

• Used to notify to the Customer facing IPTV Application with information related to the service selected 
(e.g. the IPTV service cannot be delivered because of network reasons - information from the Sa reference 
point). 

5.2.5 Xc - UE and IPTV Media Control Function 

Xc reference point (for media control) - logical end-to-end reference point between the UE and the IPTV Media Control 
Function (MCF): 

• used to exchange media control messages for controlling of the delivery IPTV Media flows. 

NOTE: Transport related reference points shall be used to carry media control messages over underlying transport 
segment (defined in ES 282 001 [5] and as shown below in figure 3) depending on the location of the 
MCF: the Dj reference point between the UE and the access network, possibly the Di reference point 
between the access network and the core network, and possibly the Ds or Iz reference point between the 
core network and the Media Control Function if the MCF is located after the Core Network. 
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■I 
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Xc 

Figure 3: Decomposition of thie Xc reference point whien thie IVICF is after thie Core Networic 

5.2.6 Xp - IPTV Media Control Function and IPTV Media Delivery 
Function 

• Reference point between Media Control Function (MCF) and Media Delivery Function (MDF): used to control 
media delivery sessions in order to support setup of a media delivery session. The media content can be 
distributed among one and more media delivery functions. 

NOTE: If authorization of the user access to the selected IPTV service is still valid, it may be used for 

transmission of some adaptations session control and/or media control commands to the previously 
selected/established media delivery. 

5.2.7 Xd - UE and IPTV Media Delivery Function 

Xd reference point (for media delivery) - logical end-to-end reference point between UE and IPTV Media Delivery 
Function (MDF): 

• carries IPTV media data by appropriate means to the UE (delivers content streams). 

NOTE: Transport related reference points shall be used to carry media delivery data over underlying transport 
segment (defined in ES 282 001 [5] and as shown in figure 4) depending on the location of the MDF: 

the Dj reference point between the UE and the access network, possibly the Di reference point between 
the access network and the core network, and possibly the Ds or Iz reference point between the core 
network and the Media Delivery Function if the MDF is located after the Core Network. 
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Figure 4: Decomposition of thie Xd reference point 

5.2.8 e2 - MASS access 

The e2 reference point is defined in ES 282 007 [9] and ES 282 004 [10]. 

5.2.9 e4 - MASS and RAGS 

The e4 reference point is defined in ES 282 003 [1 1] and ES 282 004 [10]. 
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5.2.10 Gq'-RACS 

5.2.1 1 Sh - IPTV applications and UPSF 

• Reference point between IPTV applications and UPSF [5]: As an application server function may choose to 
use the repository function of the UPSF for hosting service-level user data, as transparent data, the Sh 
reference point is used between this AS Function and UPSF. 

• The use of Sh reference point conforms to ES 282 007 [9]. 

• The IPTV applications represented on figure 2, that may use the UPSF repository function are: Customer 
Facing IPTV Applications, IPTV control. 

5.2.12 Ud - IPTV applications and lUDF 

• Used by IPTV application server functions to access IPTV profiles subset which are hosted in lUDF. 

• The IPTV applications represented on figure 2, that may use the UPSF repository function are: Customer 
Facing IPTV Applications, IPTV control. 

5.2.13 Ug - access to federalized NGN data 

• Used by IPTV applications to access federalized data from service level subsystems (to provision and give 
access to IMS, mobile, other profile data. 

• Used by converged applications (e.g. communicational features on TV, mobile session handover) to access 
federalized data from service level subsystems (e.g. to provision and give access to IMS, mobile, other profile 
data). 

• Provides common access among application to profile data models and data components that are common 
across applications. 

6 Operational framework 

6.1 IPTV delivery modes 

Dedicated IPTV subsystem supports IPTV or NGN service using IP delivery modes: 

• Unicast: delivery mode where information packets are sent to a single destination. 

• Multicast: delivery mode of forwarding information packets to a group of destinations. 

• Combinations and interchanging of both inside a given service. 

In order to implement service level requirements defined in [1], dedicated IPTV subsystem can use IP unicast delivery 
mode, for example, for Content on Demand service, or IP multicast delivery mode, for example, for broadcast TV 
service. More complex service scenarios are possible, where IP delivery modes are interchanged inside a single service, 
for example, to implement broadcast TV with trick modes. 

Unicast and multicast capabilities are expected from the transport layer. However, if only a subset of delivery 
capabilities is available, the functional architecture would implement functional capabilities build upon the available 
subset. For example, if transport layer has unicast capabilities only, the functional architecture implements CoD, nPVR 
and other services build upon unicast delivery. 



ETSI 



1 8 ETSI TS 1 82 028 V2.0.0 (2008-01 ) 



6.2 Operational modes 



This clause describes interactions between the UE, the AppHcation functions and the "IPTV Service Control and Media 
Delivery functions". 

There are two aspects of these interactions: 

• Interactions between the Application functions and the "IPTV Service Control and Media Delivery functions". 

• Interactions between the UE and the "IPTV Service Control and Media Delivery functions". 

Concerning the first aspect, there are two possible modes of operations: coupled and decoupled. 

Coupled: following a request from the UE, the application communicates with the "IPTV Service Control and Media 
Delivery functions" to allocate and reserve a media delivery function before the content selection is confirmed to the 
UE. The URL to contact the "IPTV Service Control and Media Delivery functions" is returned to the UE. 

Decoupled: following a request from the UE, the application returns the URL to contact the "IPTV Service Control and 
Media Delivery functions" assuming that the "IPTV Service Control and Media Delivery functions" will be able to 
allocate a media delivery function and associated resources when needed. 

Concerning the second aspect, there are two possible modes of operation: proxy and redirect. 

In the redirect mode: a functional entity receives an input request, performs its actions and redirects UE to the next 
functional entity in sequence. 

In the proxy mode: a functional entity receives an input request, performs its actions and proxies the request to the 
next functional entity in sequence. 

The flows for proxy and redirect modes are defined for one of the functional entities from 'IPTV service control and 
media control functions. 

IPTV control is defined in redirect mode and MCF is defined in proxy mode. 

If one of the functional entities work in either of modes it neither mandates no precludes other functional entities to 
work in the same or alternative modes. 

6.2.1 Coupled mode 

Operational flow in the coupled mode is presented on figure 5. 
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Figure 5: Operation flow in the coupled mode 

Main functional steps in the coupled mode: 

1) Service Initialization: UE selects and requests service from the application. 

2) Profile Access: The application optionally access profile information wither from application data of via data 
access functions. 

3) Media Control Function Allocation: The application request a Media Control Function the UE can contact to 
requested media. 

4) User location: user location can be requested from NASS or from IPTV UDF in order to select the appropriate 
Media Delivery Function (and Media Control Function). 

5) Resources Reservation and Admission Control: IPTV service control and media delivery functions selects a 
MCF and a Media Delivery Function and requests reservation of transport delivery resource (from UE to 
Media Delivery Function selected). 

6) Resources Reservation and Admission Control: transport resources reserved and committed. 

7) Media Control Function Allocation: Allocation of the user contact point in order to request media delivery and 
for interactive Media Control Function. 

8) URL for Media Delivery to content Media Control Function functional entity. 

9) Media Delivery Request: UE requests interactive media delivery. 

10) Media delivery Function: UE controls interactive media delivery. 



6.2.2 Decoupled mode 

Operational flow in the decoupled mode is presented on figure 6. 
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Figure 6: Operation flow in thie decoupled mode 

Main functional steps in the decoupled mode: 

1) Service Initialization: UE selects and requests service from the application. 

2) Profile Access: The application optionally access profile information wither from application data of via data 
access functions. 

3) URL for Media Dehvery. 

4) Media Control Function Allocation: Media Delivery Request. UE requests interactive media delivery. 

5) User location: user location can be requested from NASS or from IPTV UDF to select the appropriate Media 
Delivery Function (and Media Control Function). 

6) Resources Reservation and Admission Control: IPTV service control functions selects and media delivery 
functions selects a MCF and a Media delivery entities and requests reservation of transport delivery resources, 
(from UE to Media Delivery Function selected). 

7) Resources Reservation and Admission Control: transport resources reserved and committed. 

8) Media Control Function Allocation: Allocation of the user contact point in order to request media delivery and 
for interactive Media Control Function. 

9) Media Delivery Request: UE requests interactive media delivery. The UE knows it has to send a second 
request because request at step 4 has resulted in redirect response as defined in clause 6.2.3. 

10) Media Delivery Control: UE controls interactive media delivery. 

6.2.3 Redirect mode 

Operational flow of the IPTV control functional entity in the redirect mode is presented on figure 7. The flow represents 
operational. 
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Figure 7: Operation flow in thie redirect mode 

Main functional steps in the decoupled mode: 

1) Media Delivery Request: UE requests interactive media delivery. 

2) Authorization Verification: IPTV control optionally verifies user rights to access the service. 

3) User Location: user location can be requested fi^om NASS or fi^om IPTV UDF. 

4) Resources Reservation and Admission Control: IPTV control selects media delivery function and optionally 
requests reservation of transport delivery resources. Note: resource reservation can be alternatively performed 
by the selected MCF. 

5) Resources Reservation and Admission Control: transport resources reserved and committed. 

6) Redirect to MCF: UE is redirected to MCF for the selected MDF function for interactive media delivery. 

7) Media Delivery Request: UE requests interactive media delivery. 

6.2.4 Proxy mode 

Operational flow of the MCF control functional entity in the proxy mode is presented on figure 8. 
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Figure 8: Operation flow in the proxy mode 

1) Media Delivery Request: UE requests interactive media delivery. 
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2) Authorization Verification: MCF optionally verifies user rights to access the service. May access to IPTV 
UDF for this purpose. 

3) Resources Reservation and Admission Control: MCF selects media delivery function and optionally requests 
reservation of transport delivery resources. Note: resource reservation can be alternatively performed by the 
IPTV control. 

4) Resources Reservation and Admission Control: transport resources reserved and committed. 

5) Media Delivery Request: Media Control Function command is passed to media delivery. 

6) Media Delivery: media is delivered to the UE. 



6.3 



Service initialization 



6.3.1 Functional steps for UE start-up 

Figure 9 presents functional steps of the UE start-up for IPTV subsystem in NGN. 
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Figure 9: UE start-up procedure 



1) Network Attachment. 



2) 



In this step, the UE attaches to the network. The UE may be passed data for service provider discovery as 
defined in clause 5.2.1. 



Service discovery. 

In this step, the UE discovers service providers and services as discussed in clause 5.2.1. 

3) IPTV security bootstrapping 

In this step, the UE performs authentication, key management. During this procedure IPTV subsystem may 
register IPTV UE in other service level subsystems on behalf of UE. 

4) Attach to the IPTV Service. 

5) IPTV Service Configuration. 

In steps 4 and 5, the UE navigates and selects a service from available service offers. IPTV AS may update IPTV user 
profile, presence of behalf of IPTV as a part of the SD&S process. The service navigation and selection can be provided 
in a generic case via different functional entity as presented on figure 10. 
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NOTE: The high level service attachment steps can looks similar for dedicated IPTV subsystem and IMS based 
IPTV approaches, the exact alignment in procedures is out of the scope of the present document. 

6.3.2 Service discovery and selection 

This clause defines steps in the service discovery and selection process used by the UE to attach to the network, acquire 
list of service providers and make service selection from the selected service provider. 

There is a step preceding SD&S process including setup and initial UE configuration. 

Figure 10 presents steps in the SD&S process. 
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Figure 10: High Level SD&S Process 

Network Attachment: during this step UE establishes connectivity to an IP-network and obtains network-based service 
configuration data. For example, the following information may be obtained or established by UE: IP address, network 
mask, DNS, domain name, others. During this step UE may be passed data for service provider discovery, e.g. a 
container option sent by DHCP server listing the source IP address of the Service Provider server or list of registered 
IPTV service provider servers using DNS SRV mechanism in accordance with RFC 2782 [8]. 

Service Provider Discovery: during this step UE collects the location (entry points) for discovering service providers 
and retrieves information about available IPTV Service Providers, learns the location of their one or more Service 
Discovery (SD) Server. 

Service Discovery and Attachment: during this step UE acquires information about available IPTV Services from one 
or more Service Discovery (SD) Servers, navigate, select service from the service offering and attach to the service. The 
procedure used to activate a particular IPTV service is typically service specific. Authentication is performed at this 
step. 

Further decomposition for Service Provider Discovery is presented on figure 1 1 . 
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Figure 1 1 : Service Provider Discovery Steps 

Entry points discovery: during the step UE determines the entry point(s) for discovering service providers 
(e.g. bootstrap process). 

Service provider selection: during this stage UE retries information about available IPTV Service Providers, learns the 
location of their one or more Service Discovery (SD) Servers and makes a selection of the Service Provider. 

Different mechanisms are available for Step 2 and Step 3, e.g. those defined in DVB-IP [2] can be used. 

Regionalized or personalized delivery of the content metadata can be performed by the Customer Facing IPTV 
applications by accessing user profiles (as described in the Clause 8) and accessing user location (as described in 
clause 5). 

6.4 Nomadism 

In TISPAN Release 2, nomadism can be provided by relying on the functionality provided by the transport control 
layer (i.e. RACS and NASS). In this scenario, all functions in the dedicated IPTV subsystem are located in the user's 
home domain and therefore, a UE in a visited access network or access point needs to be provided with: 

IP connectivity to the user's home service control domain. 

A pointer to the Customer Facing IPTV Application in the user's home service control domain (as part of the 
Service Discovery and Attachment procedures described in clause 6.3.2). 

This release does not describe how nomadism may be provided by the dedicated IPTV subsystem at the service control 
layer (i.e. by having IPTV functions that are distributed across the home and visited networks). 



7 Security 

For content security the following elementary functions are used: 

• Content licensing: This elementary function handles the Ucenses issuing related functions, including 
generation and distribution of the licenses to the desired entities. 

• Key management: This elementary function handles the management of the security keys, including generate 
and provide the keys and corresponding parameters to the desired entities. 

• Content encryption: This elementary function handles the content protection related operations, e.g. content 
encryption and encapsulation operations etc. 

These three elementary functions may be flexibly located in existing functional entities or new ones as a whole or in 
independent parts. 

NOTE 1 : The locations and related reference points of those three elementary functions are defined in 
TS 187 003 [12]. 

NOTE 2: Some of these elementary functions may be executed on-line (in real-time) or off-line (in this case could 
be part of the management). 
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8 Management 



A number of functional entities used to deliver IPTV and NGN services require time synchronization, e.g. to provide 
time of day reference. Transport layer should support such reference. 

Content management functionalities are responsible for managing acquisition of content and service information 
(e.g. metadata) from sources, controlling validation and/or processing/adaptation to the required format and also to 
provide management functionalities for supporting distribution of content to the media delivery function. 

NOTE: Content management is used in the case of offline or online ingest of the content. The online ingest means 
receiving content directly streamed from the content provider. The offline ingest refers to content files 
delivered by other means than the online (e.g. such on physical media like DVD, CD, etc.). The content 
management is used by the IPTV service provider to statically provision the content. 



9 User data 

9.1 IPTV profiles 

IPTV related data can be grouped into three types of IPTV profiles (figure 12): 

• Content Profile. 

• Service Profile. 

• User Profile. 
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Figure 12: NGN IPTV profiles 

Content Profile: Content profile contains and maintains information about multimedia metadata and multimedia 
service packaging used for the provisioning of IPTV services. 
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Figure 13: NGN IPTV Service Profile 
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Service Profile: Service profile refers to data used to the provisioning of the service to the user. It contains and 
maintains information about service-level user data and service-level offer data (figure 13): 

• Service-level user data: as defined in NGN Functional Architecture [5], e.g. user identification, numbering, 
addressing, user security, location information at inter-system level, other. 

• Service-level offer data: contains the information for delivery of IPTV services, e.g. EPG/BPG. 

User profile: User profile refers to user customization and usage metadata. It contains and maintains basic user 
information, service specific information, e.g. subscription, bookmarks, activities, parental control, etc. and User actions 
related to service purchase and consumption. 

• User subscription data - contains information such as language preference, payment preferences, navigation 
preferences, etc. 

Service actions data - contains and maintains non static data related to the purchase and consumption of services such as 
list of CoD already consumed, indexes for currently consumed programs, language selection. 

9.2 User data location 

Both lUDF and UPSF may be used for handling the IPTV related user data. 

IPTV profile information (Content, service, user, as defined in clause 8.1) could be optionally located in the IPTV 
Application server functions (i.e. lUDF) hosting the IPTV applications, or in the UPSF as transparent data associated to 
the Application Server functions, or in an XDMS associated with the IPTV Application Function. 

The type of user related information necessary for multi-subsystems service blending belongs to the following list: 
service-level user identification, numbering and addressing information, service-level user security information: access 
control information for authentication and authorization, service-level user location information at inter-system level, 
service-level user profile information. 

To provide support for converged applications (such as chatting on watched programs, multiple incoming calls 
management, etc., as listed in TS 181 016 [1] that span across several subsystems of the TISPAN NGN network), 
several options are then provided, in accordance with the location where the user data is: 

• Use UPSF as the host for the set of user related information necessary for multi-subsystems service blending. 

• Use of data federalisation (represented by UDAF on figure 2). 

It is recommended that an NGN (e.g. converged) application, or its corresponding user data functions do not have direct 
access to IPTV profiles in lUDF (reverse applies respectively). It may however have access to it by other means 
(e.g. Ug reference point to UDAF, Sh to UPSF for the subpart of IPTV profile that is hosted onto UPSF. 

If UPSF is used, several entities will need to be consistently provisioned for: 

• user identification (in UPSF and lUDF); 

• user authentication (in UPSF and lUDF). 

NOTE: Such need for consistent provisioning is to be brought to the attention of WG8. 



10 Charging 

As illustrated in figure 2, the charging belongs to the management domain. 

IPTV subsystem collects information related to billing and provides IPTV CDRs (including charging related elements), 
that can be collected by the billing system for the sake of off-line charging. These CDRs may also be used for other 
purposes than billing (such as QoS, statistics). 

NOTE: CDR means Charging Data Record, as defined in TS 132 240 [14] (endorsed by ES 282 010 [13]). It is a 
formatted collection of information about chargeable event, knowing that, as a minimum, a chargeable 
event characterizes the resource/ service usage and indicates the identity of the involved end User (s). 
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IPTV subsystem integrates with the charging and accounting components of the management domain for having access to 
the user account (credit, balance, etc.) in order to allow IPTV user facing applications and optionally media delivery 
control to performs their role with. 



11 



Procedures 



11.1 Linear TV 

This clause provides the flows for the BTV IPTV services integrated into the TISPAN NGN architecture and 
inter-working with the NGN common functions and components. 

The clause presents generic flows and does not mandate placement of functions. DRM flows are not included. 
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Figure 14: NGN IPTV Linear TV procedure 

1) UE requests SD&S information from SD&S. SD&S format and request methods are outside the scope of the 
present document and have been researched in other specifications, e.g. [2], others. 

2) SD&S verifies user profiles from UDAF/UPSF. The location of UDAF/UPSF and data model, e.g. centralized 
or federated is described in clause 9. 

3) SD&S replies service offers to UE. 

4) MDF outputs BTV multimedia stream, such as regular TV channels or scheduled content, to the transport 
connected via MGF. 

5) UE requests transport to join linear TV channel A (BTV multicast stream). 

6) Optionally, resource admission control may take place at this stage. For Multicast, this is typically performed 
by an A-RACF, which can be separately located or collocated with the Transport Processing Function [7]. 

7) Channel A is delivered. 

8) UE requests transport to leave linear TV channel A. 
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9) UE requests transport to join linear TV channel B. Optionally, local admission control can check resource 
availability before granting the request. 

10) Optionally, resource admission control may take place at this stage. For Multicast, this is typically performed 
by an A-RACF, which can be separately located or collocated with the Transport Processing Function [7]. 

11) Channel B is delivered. 

NGN Linear TV IPTV session is a lasting service agreement and reserved network delivery resources for broadcast 
multimedia service between UE and Transport, e.g. between and including steps 5) and 8) on figure 14. 

NOTE: This and subsequent flows show separate location of the transport and RACS, they can be co-located as 
discussed in [7]. 

1 1 .2 Multimedia content on demand (CoD) 

This clause provides the flows for the CoD IPTV services integrated into the TISPAN NGN architecture and 
inter-working with the NGN common functions and components. 

The clause presents generic flows and does not mandate placement of functions. DRM flows are not included. 
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Figure 15: NGN IPTV CoD procedure 

1) UE requests SD&S information from SD&S. SD&S format and request methods are outside the scope of the 
present document and have been researched in other specifications, e.g. [2], others. 

2) SD&S verifies user profiles from UDAF/UPSF. The location of UDAF/UPSF and data model, e.g. centralized 
or federated, is described in clause 9. 



£75/ 



29 ETSI TS 1 82 028 V2.0.0 (2008-01 ) 



3) SD&S replies service offers to UE. 



4) User selects a service from the offers. UE requests the selected service from Customer Facing IPTV 
Applications. 

5) Customer Facing IPTV Applications, optionally creates billing event, e.g. for on-line billing, and sends it to 
UDAF/UPSF. The location of the billing information and data model are discussed in clause 9. 

6) Customer Facing IPTV Applications optionally creates authorization record (play ticket) to authorize content 
delivery. 

7) Customer Facing IPTV Applications replies the location of IPTV control and optionally ticket data to UE. 

8) UE requests IPTV control the location of MCF. Optionally ticket data is supplied. 

9) IPTV Control selects MCF based upon operator defined criterions and requests RACS to allocate resources 
between the end-points. Distributed RACS interfaces are allowed. 

10) IPTV Controls rephes MCF location to UE. 

1 1) UE requests MCF to deliver media using reserved session and associated resources. Optionally ticket data is 
supplied and the ticket punched. 

12) MCF optionally verifies user credentials to request multimode delivery. 

13) UE utilizes VCR style control over media to MCF. 

14) Automatic resource reservation follows session termination, which can be initiated either by end point UE or 
MCF, or by an IP network. Although it is not necessary to explicitly tear-down an old reservation, we 
recommend that during normal operation MCF or IPTV Control send a teardown request to RACS as soon as 
the session has finished. 

NGN CoD IPTV session is a lasting service agreement and reserved delivery resources on server and network levels for 
multimedia on demand service between UE and MDF. 

Cod flows do not cover NAT explicitly, however, standard IP NAT protocols can be used, see [15]. 

1 1 .3 Media broadcast with trick modes 

This clause provides the flows for the media broadcast with trick modes IPTV services integrated into the TISPAN NGN 
architecture and inter-working with the NGN common functions and components. 

The clause presents generic flows and does not mandate placement of functions. DRM flows are not included. 



£75/ 



30 



ETSI TS 182 028 V2.0.0 (2008-01) 



UE 



Transport 



RACS 



(1) 



(2) 
(3) 
(4) 



(5) 

(6) 

-H 
(7) 

(8) 
(9) 



(10) 



(11) 



(12) 



(13) 
(14) 



(15) 



MCF 



Acquisition of SD&S informati sn 



Linear TV 
Join channel 

Channel A 
Pause life 
Pause life 



Resource 



Pause life 

► 



MDF 



IPTV 
Control 



UDAF 



SD&S 
and 

CFIPTV 

Apps 



channels A 
A 



rv. Pause 
rV. Play f 



reservatior 



TV. Play 
Authorisation verific 



Leave chinnel A 

om the pa jse positioh. Setup 



CoDVCF- control 

► 

Automatic resource Release 



Tom the piuse positicbn. Setup 
ation 



Figure 16: NGN media broadcast with tricit modes procedure 

The flows shows generic case where MDF providing linear TV is not co-located with MCF providing 'on-demand' 
functionality. MCF and MDF can be located in the same place. 

1) UE requests SD&S information from SD&S. 

2) SD&S verifies user profiles from UDAF. 

3) Media broadcast with trick modes is a subscription based service. At the subscription time, Customer Facing 
IPTV Applications optionally create authorization record (play ticket) to authorize this service. 

4) SD&S is returned to the user. 

5) MDF outputs BTV multimedia stream, such as regular TV channels or scheduled content. 

6) UE requests transport to join linear TV channel A (BTV multicast stream). Optionally, resource admission 
control may take place at this stage. For Multicast, this is typically performed by an A-RACF, which can be 
separately located or collocated with the Transport Processing Function [7]. This is shown by a dotted line. 

7) Channel A is delivered. 

8) User requests to pause linear TV channel. UE requests transport to leave linear TV channel A. 

9) User requests to re-start play from the paused position. UE issues setup command and requests IPTV Control 
the location of the MCF. Optionally ticket data is supplied. This selection is optional, previously selected MCF 
can be used or the default MCF can be supplied to the UE during service initialization steps. 

10) IPTV control selects MCF based upon operator defined criterions and requests RACS to allocate resources 
between the end-points. Distributed RACS interfaces are allowed. 

1 1) IPTV control rephes MCF location to UE. 
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12) UE issues play command and requests MCF to deliver media from the pause position supplying position. 

13) MCF optionally verifies user credentials to request multimode delivery. 

14) UE utilizes VCR style control over media. 

15) Automatic resource release follows session termination, which can be initiated either by end point UE or MCF, 
or by an IP network. Although it is not necessary to explicitly tear-down an old reservation, we recommend 
that during normal operation MCF or IPTV Control send a teardown request to RACS as soon as the session 
has finished. 

Return to live linear TI channel is achieved by repeating steps 6) and 7). 

Return to trick mode is archived by repeating steps 8) to 13). 

NGN IPTV media broadcast with trick modes service is combination of separate BTV and CoD IPTV sessions joined 
together at the service level. See clause 11.1 for definition of CoD NGN IPTV session and clause 11.2 for definition of 
BTV NGN IPTV session. 

NGN IPTV media broadcast with trick modes session is a service level aggregation as defined above and is not used for 
billing purposes. 

11.4 Near CoD 

This clause provides the flows for the Near CoD IPTV services integrated into the TISPAN NGN architecture and inter- 
working with the NGN common functions and components. 

The clause presents generic flows and does not mandate placement of functions. DRM flows are not included. 
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Figure 17: NGN IPTV Near CoD procedure 

The flow shows generic case where MDF providing a CoD content on a set of muhicast channels with a fixed interval, 
e.g. an interval of 15 minutes. 

For example, one content's playback time is 148 minutes. 

Near CoD Channel starts output stream at time offset 00 minutes. 

Near CoD Channel 1 starts output stream at time offset 15 minutes. 



ETSI 



33 ETSI TS 1 82 028 V2.0.0 (2008-01 ) 

Near CoD Channel 2 starts output stream at time offset 30 minutes, and so on until. 
Near CoD Channel 9 starts output stream at time offset 135 minutes. 

(1) IPTV Control requests the MDF to initiate the Near CoD channels. 

(2) MDF outputs Near CoD channel streams to the transport. 

(3) UE requests the Near CoD services information from SD&S. 

(4) SD&S checks the user profiles from UDAF/UPSF. 

(5) SD&S returned Near CoD Services offered. 

(6) UE purchase the Near CoD from CF IPTV Applications. 

(7) CF IPTV Applications updates the user profiles from UDAF/UPSF to record the purchase. 

(8) CF IPTV Applications returned the Channel list of the Near CoD Service which the user just purchased. Each 
channel has an information of Start Time and End Time. 

(9) UE requests transport to join Near CoD channel / which was the next rolling start channel by the time of the 
request. 

(10) Optionally, resource admission control may take place at this stage. For Multicast, this is typically performed 
by an A-RACF, which can be separately located or collocated with the Transport Processing Function [7]. 

(11) Near CoD Channel / is delivered. 

(12) User requests to Skip Forward. UE requests transport to leave Near CoD Channel +1. 

(13) UE requests transport to join Near CoD channel +i+l which was the next channel. 

(14) Optionally, resource admission control may take place at this stage. For Multicast, this is typically performed 
by an A-RACF, which can be separately located or collocated with the Transport Processing Function [7]. 

(15) Near CoD Channel i+1 is delivered. 

(16) User requests to Skip Backward. UE requests transport to leave Near CoD Channel i+1. 

(17) UE requests transport to join Near CoD channel / which was the previous channel. 

(18) Near CoD Channel / is delivered. 

(19) User requests to Stop or End play the Near Cod. UE requests transport to leave Near CoD Channel +i. 
Step (1) and (2) is the flow of setup of Near CoD. 

Step (3) to (8) is the flow of Service Discovery & Selection of Near CoD. 

Step (10) to (17) is the flow of UE playback control of Near CoD. Step (12) to (16) are the optional interaction flow 
during the playback of Near CoD. 



£75/ 



34 



ETSI TS 182 028 V2.0.0 (2008-01) 



Annex A (informative): 

Interactions between other NGN services and IPTV services 

In order to implement service level interactions between IPTV and other NGN services as defined in [1] common NGN 
ASF can be used for interactions with other applications and services, e.g. between IPTV and IMS. 

A common ASF can be used for delivering customized notifications from multiple service domains (notification 
sources), e.g. IMS-IM, IMS call alert, emergency notification, SMS message, e-mail alert, RSS feed, other to IPTV UE. 
E.g. the notifications could be delivered to the UE based on user profile, location, presence and may require response 
from the UE. This functionality is illustrated in figure A. 1 . 

A common ASF can be used for presence, e.g. presence server as discussed in annex C. 
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Figure A.1 : Interactions between IPTV and other NGN applications and services 

NOTE: Such interactions are based upon existing interfaces. 
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Annex B (informative): 

Interaction procedure between IPTV and other service level 

subsystems 

This clause provides interaction procedure between IPTV and other service level subsystems, e.g. IMS, for composite 
services. The flow assumes that users are registered in IMS subsystem. 

The procedure describes multimedia and communication features in converged NGN IPTV applications: caller ID on 
the TV screen User 1 calls User 2 and both are in IMS domain. User 2 is subscribed to a converged IPTV service - 
caller ID notification with options to accept, forward or reject incoming call when another IPTV service is active via the 
IPTV UE. 

The clause presents generic functional steps and does not mandate placement of functions. DRM functions are not 
included. 
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Figure B.1 : High level interactions procedure between IPTV and 
other service level subsystems - IMS/IPTV inter-working 

1) User 1 initiates a call to user 2 from his IMS device UEl. After traversing through the IMS CSCF chain 
invitation (e.g. SIP INVITE) is deUvered to the S-CSCF for User 2. 

2) S-CSCF access user profile data. Dotted arrow indicate that IMS user profile has been requested from UPSF. 

3) S-CSCF, based upon IMS user profile, sends the invitation on ISC interface to common NGN ASF-. The NGN 
ASF is an Application Server Function. Optimizations are possible, e.g. a timer in S-CSCF can automatically 
deliver call upon no response. 

4) NGN ASF checks IPTV user profile: 

a) either by requesting IPTV sub-profile of federalised user profile from NGN UDAF; 

b) or directly from IPTV subsystem from lUDF. 
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5) NGN UDAF optionally request lUDF for IPTV profile. 

6) lUDF returns requested information. 

7) IPTV user profile information is returned to NGN ASF. 

8) NGN ASF, based on IPTV user profile and presence, delivers incoming call notification either to the IPTV 
ASF (Customer facing IPTV application) or directly to the IPTV UE. In the first case steps 9) and 10) are 
optional. Common NGN ASF and other ASF can be located separately, co-located or can be deployed as 
application package. They are shown separately to cover generic case. 

9) IPTV ASF invokes IPTV application to show call line ID to IPTV UE2. 

10) User 2 from IPTV UE chooses to answer the call on IMS UE. 

1 1) IPTV ASF (or IPTV UE) notifies NGN ASF that the call setup can be continued. 

12) NGN ASF returns invitation to S-CSCF to be delivered to User 2 IMS home device. 

13) S-CSCF delivers invitation to User 2 IMS home device. 



£75/ 



37 ETSI TS 1 82 028 V2.0.0 (2008-01 ) 



Annex C (informative): 
Presence attributes for IPTV 

IPTV services may be combined with the presence service capability. 
The following specific IPTV attributes shall be supported: 

• Broadcast TV with or without trick modes service activated. 

• CoD service activated. 

• PVR service activated. 

• Near CoD (nCoD). 

• Interactive TV service activated. 

The following specific IPTV attributes may also be supported: 

• Service currently accessed. 

• Content currently accessed. 

• Presence filtering for buddy list members. 

• Buddy list management. 

It is up to user's decision to include specific IPTV attributes in Presence document. 

Service level requirements [1] require that IPTV solution should be able to access and provide presence information. It 
is outside the current release to evaluate whether there is sufficient access to the presence service (i.e. the attribute 
described) for dedicated IPTV subsystem. 
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